In the past, communication between computer processes took one of two general forms. Programs running on different machines would communicate by using a data communication, or datacomm, method. Programs running on the same machine would employ an inter-process communication method. Both methods could be implemented in a variety of ways requiring programmers to implement a multiplicity of communication protocols to permit a program to communicate within a platform and across platforms.
The datacomm method required writing a program to conform to a specified data communications protocol and required the program to interact with a low-level datacomm driver program which managed the hardware to perform such communications. This method limited programs running on a given platform to communicating only with programs on other hardware platforms on which a compatible driver was implemented. In addition, the programs which are to communicate must utilize the correct protocol and driver. This can severely limit the number of programs and classes of machines with which a program can communicate.
The datacomm protocol and the associated drivers were not suitable for communication by processes executing on the same machine. That is the driver could not handle communication between processes on the same machine. The mechanism used to accomplish such communication was usually to define and use an inter-process communication protocol. Such a mechanism requires programs that wish to communicate to cooperate. That is, there is a requirement that the programs adhere to the specific protocol and use a pre-defined path of communication. Once written and compiled, changes may be made to the communication path and protocol only by re-coding and recompiling the program involved. Note also that both the sending and receiving program must adhere to this same protocol.
Generally, once the program is written for a specified path using a specified protocol, the program must be rewritten and re-compiled if any changes to this path are necessary. One of the better methods known to change a path is found in the UNIX operating environment which provides the concept of "streams". A stream permits the path to be altered by interposing a series of modules between the program and the end of the stream. However, these modules may still only be interposed programmatically in that the program must call the ioctl() routine to add a module to the stream. In this sense, the program must still be tailored to the specific path stream. To change the path, the program must be changed, re-compiled and relinked. Note also that the use of streams is limited to machines which support the UNIX operating system. Another limitation is that the receiving program must adhere to the UNIX protocol for the use of streams.